1. Field of the Invention
The present invention relates generally to a method and apparatus for managing media data in computer network systems. More specifically, the present invention relates to a process and apparatus providing a centralized graphical user interface for managing media assets in a network by specifying and scheduling operations to be performed by a plurality of media servers in a computer network.
2. Description of the Prior Art
A media server is a network server system which is operative to perform various operations on media data files in a computer network system. Digital media files may include video data, audio data, text data, and graphical data. Typically, a media server is operative to perform media operations including: delete operations for deleting media assets from locations in a network; copy operations for copying media assets from source locations to destination locations in a network; multicasting operations for streaming media assets from the media server to clients via the network; and encoding operations for encoding media data, received by the media server from multimedia equipment such as a video camera, in order to create media assets.
For purposes of the present application, a media asset is defined to include parsed media data which is configured to be streamed from a media server to one or more clients in a particular type of network. One example of a media server is IBM's VideoCharger™ server and media streamer which combines functions of digital computing and the video broadcast industry into a versatile, cost-effective system for high-quality storage and delivery of multimedia content. Details of the VideoCharger™ product are disclosed in U.S. patent application Ser. No. 08/961,704, entitled “Scaleable Network Transparent Access Framework for Multimedia Serving,” filed on or about Oct. 31, 1997, and U.S. patent application Ser. No. 08/961,706, entitled “Seamless Playlist,” filed on or about Oct. 31, 1997, each of which is hereby incorporated.
The VideoCharger™ server, provided by International Business Machines Corp., provides one example of a media server. The VideoCharger™ server provides for the delivery of continuous time media data (i.e. audio and/or video data) to Internet or Intranet connected clients. The video is “streamed”, (i.e. delivered in real-time) and does not require that the file be downloaded or saved before being played by the client software. In video parlance, the video is “pushed” by the server over the network to the client. This approach is different from most file servers where the data is “pulled” by the client issuing successive “reads” to the server. The “push” architecture is similar to a broadcast environment where a video stream is started by a play command and will continue until stopped. U.S. Pat. No. 5,918,020, issued to Blackard et al. on Jun. 29, 1999 describes a data processing system and a method for implementing a push, or streaming, model for communicating time sensitive encoded data, such as video and audio data, in a communication network. In addition to supporting industry standard file formats for audio and video, the VideoCharger media server supports the popular Internet and World Wide Web (WWW) protocols including IP and Hyper Text Transport Protocol (HTTP). This allows the product to be used with Industry standard applications like HTML Web Browsers. It also allows the product to be used on a wide variety of network types including LANs (Local Area Networks such as Ethernet, Token Ring, FDDI), WANs (Wide Area Networks such as T1, E1, T3, E3) and ATM (Asynchronous Transfer Mode).
An IP multicast feature of the VideoCharger™ media server allows it to be used as a broadcast type server in the Internet environment. This allows a single audio or video stream to be sent to multiple clients, thereby reducing the bandwidth requirements on the network. In addition, VideoCharger on Windows NT offers embedded encoder support. This allows an MPEG encoder to be installed on the server and have VideoCharger directly control the encoder for functions such as real-time IP Multicast and real-time IP Multicast with live recording of the same stream. This is a very efficient yet powerful method of providing a broadcast of a live event while recording it for later re-broadcast with minimal network load. IBM also provides a VideoCharger Server for AIX.
The functions and capabilities of media servers are very useful to archivists, film/video production groups, educational institutions, research groups, medical technologists, advertising and creative agencies, print and Web publishers, and marketing communications agencies. In accordance with prior art asset management and scheduling methods, an administrator of a media server having access rights thereto may configure the media server to execute specified media operations to be performed by that server in accordance with a specified schedule.
In accordance with one prior art asset management and scheduling method, a administrator may configure a particular media server to perform particular types of media operations by downloading hypertext markup language (HTML) Web pages via corresponding uniform resource locators (URL's) from the particular media server, each of the HTML Web pages providing an interface for scheduling a corresponding one of the particular types of media operations to be executed by the particular media server. A copy/delete HTML Web page provides rudimentary interface functions allowing the administrator to define and schedule copy operations and delete operations to be performed by the particular media server. The copy/delete HTML Web page includes: prompts and active areas enabling the user to specify a copy operation or a delete operation; and text boxes enabling the administrator to enter a path to a selected media file which the subject of the copy or delete operation. An encoding HTML Web page provides rudimentary interface functions allowing the administrator to activate an encoding operation to be performed by the particular media server. The encoding HTML Web page includes text boxes enabling the administrator to enter: a path and a selected file name for the asset to be encoded; and a duration value indicating a duration for the encoding operation. A problem associated with this prior art method of remotely activating an encoding operation is that the administrator is not provided with any view of the scene to be encoded. A multicasting HTML Web page provides rudimentary interface functions allowing the administrator to schedule a multicasting operation to be performed by the particular media server. The multicasting HTML Web page includes text boxes enabling the administrator to enter: a path indicating a selected asset to be multicasted; one internet protocol (IP) address and port number for multicasting the selected asset; a scheduled start date and start time for executing the multicasting operation; and a duration value indicating a time duration for the multicasting operation.
One problem associated with the above described prior method of configuring media servers to manage media assets and schedule media operations is that there are no mechanisms which prevent the administrator from specifying invalid options, such as specifying an invalid path or an invalid file name for a selected asset. For example, in the course of defining a copy operation using the copy HTML Web page, if the administrator specifies an incorrect path for an asset to be copied, then the copy operation will not be successfully executed at the scheduled time. Also, the prior art interface consisting of the HTML Web pages described above provides no means for notifying the administrator as to whether or not the operation is successfully completed upon passing of the scheduled time for executing the operation. Furthermore, a failure of a particular copy operation would result in a failure of a subsequently scheduled media operation which is dependent upon the particular copy operation, as further explained below.
For a variety of multimedia network applications, it is important to be able to coordinate the scheduling of media operations to be performed by a plurality of media servers. As an example, an administrator of an educational institution such as a college or university may desire to configure one or more media servers to create, store, manage, and stream media assets. In this example, the media assets may include video data and audio data comprising a lecture given by a professor in a class room. The administrator may configure a first server, that is an encoding server, to encode media data received from multimedia equipment, such as a video camera, at a scheduled time. Alternatively, the administrator may manually control the encoding media server using a local programming interface residing at the server site to start, stop, and pause encoding of the media data generated by the camera while viewing a local screen which displays the lecture being recorded. However, there is no means provided in the prior art for remotely controlling the encoding of media assets by a media server. After the administrator encodes a new asset at an encoding media server, or schedules an encoding operation to be performed at the encoding server, the administrator may configure the encoding server to execute further operations including: storing the encoded asset in a storage device; and multicasting the encoded asset to a selected group of clients either in real time or at a later time in accordance with a programmed schedule. Further, the administrator may configure the encoding server to transfer the encoded asset to a second media server via a network.
In the above described prior art asset management and scheduling method, in order to coordinate the scheduling of media operations at the first and second servers, the administrator must access and configure each server separately. As the number of scheduled operations increases, and the number of configured media servers increases, it becomes more and more difficult for the administrator to coordinate the scheduling of the operations between the multiple servers because there is no centralized location provided in the prior art for automatically logging those operations which are specified and scheduled by the administrator to be executed at the multiple servers. A log of operations scheduled to be executed by each particular media server is stored in a log file maintained by the operating system of the particular media server (e.g., a Windows NT log file, or an AIX log file). However, the administrator must access the log file of each particular server separately in order to review operations to be performed by the particular media server.
In one particular scenario, an administrator may wish to configure a first server to: encode media data to create a new asset; and then copy the new asset at a later scheduled time to a second server. Provided that the administrator has access to the second server, the administrator may: configure the second server to multicast the encoded asset to a selected group of clients in accordance with a programmed schedule; and configure the second server to subsequently remove the encoded asset from the catalog of the second server so that the new asset cannot be accessed after a certain period of time. The administrator may wish to configure the two servers to perform the steps of creating a new asset at the first media server, transferring the new asset to the second server, and multicasting it from the second server in order to achieve the goal of minimizing network congestion problems which would arise in streaming directly from the first encoding server to the selected clients. Note that the success of the multicasting operation scheduled for execution by the second server is dependent upon the success of the copy operation scheduled for execution by the first server. As mentioned above, a failure of the copy operation would result in a failure of the subsequently scheduled multicasting operation which is dependent upon the copy operation. Because there is no means for notifying the administrator as to whether or not the copy operation is successfully completed, the administrator also would have no warning that the dependent multicasting operation would inevitably fail as well.
In the above described prior art asset management and scheduling method, in order to coordinate the scheduling of media operations at the first and second servers, the administrator could separately access the log files of the first and second servers, and review each. However, this process is very cumbersome. If the administrator needs to coordinate and schedule events at a multiplicity of media servers, which may be residing in different time zones, the coordination and management of the scheduled events at the multiplicity of servers becomes very difficult.
Therefore, one problem with the prior art asset management and scheduling processes is that an administrator of a plurality of media servers is required to interface separately with each media server in order to read the log files for the purposes of coordinating scheduled operations at each of the media servers. Another problem is that the administrator is prone to specify invalid paths for assets to be operated upon thereby resulting failure of media operations. A further problem is that there is no notification system for notifying the administrator in the event of success or failure of the scheduled operations.